Modelado basado en Escenarios

Tema 6: Casos de Uso y Documentación

Ingeniería de Requerimientos de Software | Nivel: Intermedio

→ Navegación con flechas del teclado

INTRODUCCIÓN

¿Por qué Casos de Uso?

🎯 Contexto del Proyecto

En todo proyecto de desarrollo de sistemas es fundamental aclarar el alcance y objetivos antes de comenzar el diseño y construcción.

Preguntas Clave

❓ ¿Cómo clarificar?

¿Cuáles son los mecanismos más adecuados para clarificar los requerimientos del cliente?

🛠️ ¿Qué herramientas?

¿Qué herramientas se pueden utilizar para comunicar los requisitos?

✅ ¿Cómo validar?

¿Existe algún documento para validar si el software alcanzó sus objetivos?

💡 La Respuesta: Casos de Uso

Los casos de uso son la herramienta fundamental en la ingeniería de requerimientos que permite documentar los requerimientos de forma clara para el cliente y el equipo de desarrollo.

6.1 FUNDAMENTOS

¿Qué es un Caso de Uso?

📖 Definición

"El caso de uso es una secuencia de acciones que un sistema debe realizar en el contexto del negocio a través del usuario o el actor"

— Tsui, Karam y Bernal (2013)

Objetivo Principal

Establecer los pasos que un usuario realizaría en el sistema para llevar a cabo una función que necesita, así como las reglas de negocio que serán marco de referencia.

✓ Beneficios

  • Claridad en interacciones
  • Documentación comprensible
  • Validación con usuario final
  • Base para desarrollo

⚠️ Importante

"Un caso de uso es tan bueno como lo sean sus autores. Si la descripción es poco clara, el caso de uso será confuso o ambiguo."

— Pressman (2010)

ACTORES

Paso 1: Describir los Actores

👥 ¿Qué es un Actor?

Cualquier persona, dispositivo o mecanismo automático que se comunica con el producto de software.

Puede ser: una persona, un sistema externo, una base de datos, o incluso otro caso de uso.

🎯 Actores Primarios

Definición: Entidades que necesitan interactuar con el sistema para obtener un resultado esperado.

Ejemplos:

  • Cliente que reserva vuelo
  • Empleado que consulta nómina
  • Paciente que agenda cita
  • Usuario que hace compra en línea

🔧 Actores Secundarios

Definición: Realizan funciones que soportan las acciones que producirán el resultado esperado por los actores primarios.

Ejemplos:

  • Base de datos de empleados
  • Servidor de pagos
  • Sistema GPS
  • API de tráfico en tiempo real
💡 Roles del Actor

Cuando el actor es una persona, identifica su rol específico al interactuar con el sistema:

Operador, Empleado, Analista Financiero, Administrador de BD, Gerente, Cliente, etc.

ACCIONES

Paso 2: Listado de Acciones

📝 Generar Listado de Acciones

Lista de acciones que realizan los actores (primarios o secundarios) para obtener el resultado deseado.

✈️ Ejemplo: Sistema de Reserva de Vuelos

El actor (Cliente) puede realizar:

  1. Consultar disponibilidad de vuelo
  2. Consultar tarifas y promociones
  3. Reservar un vuelo
  4. Cancelar una reservación
  5. Consultar términos y condiciones del servicio
💡 Observación Importante

El actor realiza varias acciones en el sistema, pero no necesariamente todas en una misma interacción.

Esto permite:

  • Describir cada acción de forma independiente
  • Facilitar la documentación
  • Permitir modificaciones posteriores sin afectar otras acciones
CONTEXTO

Paso 3: Información de Contexto

📋 Atributos de Contexto

Información que enmarca y delimita el caso de uso

Objetivo

Describe el propósito del caso de uso.

Alcance

Determina el contexto en el que aplica el caso de uso.

Precondiciones

Condiciones que se requieren antes de ejecutar el caso de uso.

Evento de Disparo

Acción que permite iniciar el caso de uso.

Postcondiciones

Estados del sistema que se presentan inmediatamente después de la ejecución.

Reglas de Negocio

Restricciones que el usuario impone como mecanismo de control operativo.

Excepciones / Alternativas

Situaciones que pueden complicar el flujo normal y sus posibles alternativas.

ESCENARIOS

Paso 4: Escenarios Principal y Secundario

📖 Descripción Paso a Paso

Describe el proceso detallado que siguen los actores.

🍳 Analogía: Receta de Cocina

Es como describir el procedimiento de una receta:

Entre más detallados sean los pasos, mejor se entenderá y se asegurará el resultado.

Escenario Principal

El flujo normal de eventos que ocurre cuando todo funciona según lo esperado.

Describe la secuencia ideal de pasos desde el inicio hasta alcanzar el objetivo.

Escenarios Alternativos

Flujos que se desvían del camino principal por excepciones o decisiones.

Describen qué hacer cuando ocurre algo inesperado o se toma una decisión diferente.

6.2 MODELOS UML

Diagramas de Casos de Uso

📊 ¿Por qué Modelar Gráficamente?

Un modelo gráfico permite expresar de forma rápida y sencilla un escenario que nos interesa resolver.

Es la forma de abstraer un problema facilitando la comunicación.

🎨 UML - Unified Modeling Language

El modelado de casos de uso fue desarrollado por Jacobson et al. (1993) y agregado como herramienta UML.

Los Diagramas Permiten Establecer:

1. Escenarios

Interacción entre personas, organizaciones o sistemas externos con el sistema

2. Metas

Objetivos que se plantea el usuario al usar el sistema

3. Alcance

Límites claros de lo que el sistema hace y no hace

💡 Efectividad

Los casos de uso son una técnica muy efectiva para indagar requerimientos y aclarar los escenarios que se podrían presentar con el sistema a los usuarios o stakeholders.

— Sommerville (2011)

DIAGRAMACIÓN

Pasos para Dibujar un Diagrama

Establece el Sistema

Utiliza un rectángulo para establecer los límites o alcances del sistema. Incluye una etiqueta que describa el sistema. Es recomendable trabajar en un solo sistema para generar un caso de uso simple.

Elige los Actores

Dibuja los actores usando una figura de persona (stick figure). Ubícalos en el lado derecho o izquierdo del rectángulo del sistema. Deja libre la parte superior e inferior. Incluye una etiqueta identificadora al pie de cada actor.

Dibuja las Acciones

Usa óvalos para las acciones. Comienza con actividades principales y continúa con secundarias. Describe cada actividad empezando por un verbo en infinitivo con textos cortos. Las actividades del sistema van dentro del rectángulo, las externas van fuera.

Asocia y Relaciona

Conecta cada actor con las actividades en las que participa usando líneas. Determina si existe alguna relación que incluya, extienda o generalice a otros casos de uso.

RELACIONES

Tipos de Relaciones entre Casos de Uso

«include»
Incluir

Permite describir con mayor detalle alguna actividad del caso de uso.

Ventaja: Dividir una actividad en módulos independientes permite reutilizarlas y evita repetir pasos.

Ej: La actividad "Pagar" puede ser reutilizada en "Comprar boleto" y "Reservar hotel"

«extend»
Extender

Muestra que un caso de uso puede incluir funcionalidad de otro bajo ciertas circunstancias.

Notación: Línea continua con flecha hacia el caso principal.

Ej: "Autenticar usuario" se extiende a "Registrar nuevo usuario"

Generalización

Técnica para gestionar la complejidad.

Coloca la actividad de forma "general" y se relaciona con actividades más específicas.

Notación: Flechas sin relleno desde lo específico hacia lo general.

💡 Ejemplo Visual

En un sistema de restaurante:

  • «include»: "Ordenar comida" incluye "Pagar"
  • «extend»: "Ordenar comida" puede extenderse a "Aplicar descuento" si hay cupón
  • Generalización: "Pagar" es general → "Pagar con tarjeta" y "Pagar en efectivo" son específicos
6.3 DOCUMENTACIÓN

Plantilla de Casos de Uso

📄 ¿Existe una Plantilla?

El formato de especificación de casos de uso debe ajustarse a las necesidades de cada organización.

Sin embargo, existen 20 secciones estándar recomendadas.

#SecciónContenido
1DiagramaDiagrama UML del caso de uso
2IdentificaciónCódigo único e irrepetible (ej: CU-LOGIN-v1.0)
3NombreDescripción breve del caso
4HistorialRegistro de cambios del documento
5AutoresNombres de quienes redactaron
6PrioridadImportancia según técnica de priorización
7CriticidadDaño potencial si el caso falla
8FuenteOrigen de información (stakeholder, doc, sistema)
9ResponsableRepresentante del usuario final
10DescripciónDescripción breve del caso de uso
DOCUMENTACIÓN (CONT.)

Secciones 11-20

#SecciónContenido
11ActoresLista de actores que participaron
12Info. ContextoObjetivo, alcance, precondiciones, evento disparo, postcondiciones, reglas negocio, excepciones
13ResultadoDescripción de resultados producidos
14Escenario PrincipalFlujo normal paso a paso
15Escenarios AlternosExtensiones y casos especiales
16Puntos ExtensiónReferencias a otros casos de uso
17Req. CalidadReferencia a doc. de requerimientos de calidad
18DefinicionesGlosario de términos, acrónimos y abreviaciones
19Firma AceptaciónEspacio para firma del responsable
20AnexosDocumentos complementarios (wireframes, etc.)
💡 Wireframes

Son prototipos que muestran cómo podría verse el sistema. Muy útiles en la revisión de casos de uso.

Deben incluir: identificador, referencia al caso de uso, fecha, historial, autor y descripción.

⚠️ Importante: Aclarar al cliente que son de referencia y el diseño podría cambiar.

ACTIVIDAD

Ejercicio Individual en Clase

📝 Crea tu Propio Caso de Uso

Instrucciones:

Elige UNO de los siguientes sistemas y desarrolla un caso de uso completo:

Opciones de Sistema:

🏥 Sistema de Citas Médicas

Paciente agenda cita con especialista

📚 Biblioteca Digital

Usuario reserva y descarga libro electrónico

🍕 Pedido de Comida

Cliente ordena comida a domicilio

🎓 Sistema Escolar

Estudiante se inscribe a una materia

ACTIVIDAD (CONT.)

Entregables de la Actividad

✅ Debes Incluir:

Diagrama de Caso de Uso

Dibuja el diagrama UML completo con: sistema (rectángulo), actores (figuras), acciones (óvalos) y relaciones.

Identificar Actores

Lista de actores primarios y secundarios con sus roles específicos.

Información de Contexto

Objetivo, precondiciones, evento de disparo, postcondiciones y al menos 2 reglas de negocio.

Escenario Principal

Descripción paso a paso (mínimo 5 pasos) del flujo normal de eventos.

Escenario Alternativo

Al menos 1 excepción o flujo alternativo.

⏱️ Tiempo: 25 minutos

Trabaja de forma individual. Puedes usar papel o herramientas digitales.

EJEMPLO COMPLETO

Sistema de Navegación GPS

🗺️ Caso de Uso: Navegar a un Destino

CU-NAVSYS-v2.5

Actores

  • Operador de rutas
  • Conductor
  • Sistema Satelital GPS
  • Servidor de tráfico

Objetivo

Mostrar ruta más óptima desde origen al destino

📋 Reglas de Negocio

RN01: La ruta debe contemplar información de tráfico en línea
RN02: El estimado debe usar límite de velocidad de 95 km/h

🎬 Escenario Principal (7 pasos)
  1. Sistema pide destino deseado
  2. Conductor ingresa dirección destino
  3. Sistema señala destino en mapas
  4. Sistema calcula ruta adecuada basada en posición actual
  5. Sistema muestra mapa con posición y ruta
  6. Sistema actualiza tiempo restante
  7. Al llegar, muestra "Ha llegado al destino"
EJEMPLO (CONT.)

Escenarios Alternativos y Extensiones

🔀 Escenario Alternativo

4a. Sistema calculará ruta evitando zonas congestionadas:

  • 4a.1 Sistema mantiene actualizada info de tráfico
  • 4a.2 Sistema recalcula ruta evitando congestión
🔗 Puntos de Extensión

Descargar información de tráfico → CU-InfoTrafico-v2.5

✅ Requerimientos de Calidad

QR.01: Tiempo de respuesta a solicitud de ruta
QR.15: Condiciones de operación

📐 Wireframe Asociado

WF-NAVSYS-v1.0 - Ruta de navegación

Descripción: Sistema mostrará posibles rutas en un color y ruta recorrida en otro color.

BUENAS PRÁCTICAS

Consejos para Documentar

✓ Hacer

  • Usar lenguaje claro y simple
  • Comenzar acciones con verbos infinitivos
  • Numerar pasos secuencialmente
  • Validar con el usuario final
  • Mantener actualizado el historial
  • Incluir códigos únicos
  • Documentar excepciones
  • Adjuntar wireframes cuando sea útil

✗ Evitar

  • Descripciones ambiguas
  • Términos técnicos sin definir
  • Casos de uso muy complejos
  • Omitir actores secundarios
  • Ignorar flujos alternativos
  • Copiar-pegar sin adaptar
  • Olvidar reglas de negocio
  • No obtener firma de aceptación
💡 Recordatorio Clave

"Un caso de uso es tan bueno como lo sean sus autores."

Invierte tiempo en redactar con claridad. Un caso de uso bien documentado ahorra tiempo y malentendidos en el desarrollo.

RESUMEN

Puntos Clave

📖 Casos de Uso

Herramienta fundamental para documentar requerimientos de forma clara para cliente y equipo

👥 Actores

Primarios (necesitan resultado) y Secundarios (soportan proceso)

📊 UML

Diagramas con rectángulo (sistema), figuras (actores) y óvalos (acciones)

🔗 Relaciones

«include», «extend» y Generalización

📄 Documentación

Plantilla de 20 secciones estándar ajustable a la organización

🎨 Wireframes

Prototipos visuales que complementan la documentación

🎯 Objetivo Final

Crear documentación de requerimientos que sea:

  • Clara: Comprensible para todos los stakeholders
  • Completa: Cubre flujos normales y alternativos
  • Validable: Permite verificar si el software cumple objetivos
  • Mantenible: Fácil de actualizar cuando hay cambios
BIBLIOGRAFÍA

Referencias

[1] Jacobson, I., Christerson, M., Jonsson, P. y Overgaard, G. (1993). Object-oriented software engineering. Wokingham: Addison-Wesley.
[2] Pohl, K. y Rupp, C. (2011). Requirements engineering fundamentals. EE. UU: Rocky Nook.
[3] Sommerville, I. (2011). Ingeniería de software (9ª ed.). México: Pearson.
[4] Tsui, F., Karam, O. y Bernal, B. (2013). Essentials of Software Engineering (3ª ed.). EE. UU: Jones & Bartlett Learning.
🔗 Recursos Adicionales

• UML.org - Especificaciones oficiales de UML
• MSDN Microsoft - Guías de diagramas de casos de uso
• IEEE - Estándares de documentación de software

¡Excelente Trabajo!

Fin del Tema 6

Ingeniería de Requerimientos de Software

Ahora puedes documentar casos de uso profesionales 💻

1 / 18